There is a need for an entity for an individual location. This will allow descriptive information, events, pictures, and anything else pertaining to a location to be defined together.
A number of issues related to Locations are discussed here: message/view/BG+Data+Model+Discussion/29953155
Objective vs. Subjective Location Entities
Different points of view:
1. Objective places only: Subjective or free-form location entries will only cause problems and should not be included in BetterGEDCOM.
- This approach assumes all locations can be mapped objectively and without ambiguity.
2. Subjective places only: All places must be free-form and not tied to external geographic mapping or naming systems or conventions.
- not advocated by anyone to date
3. Subjective places with objective geographic naming/mapping system references: Place names in BetterGEDCOM file format should be free-form and not be subjected to any external naming rules but should also include extensions within the data stream allowing reference to different geographic naming/mapping systems and information needed to map within those systems.
- This approach provides free-form flexibility for users while also preserving data for use of geographic information systems.
Location Modifiers
Location entries need to accommodate modifying adjectives, such as:
- near
- outside
- either/or ??
- suburban
- probably/possibly? (not sure about this)
- ?
Location Events
(Locations may have events. These define something that happens regarding this location at a specific date and time. The "birth" and "death" of locations should be noted as event for the location, although we may want to name them something else, e.g. "Formed", "Built", "Established", "Dissolved", "Burnt Down", "Parceled". This is useful for recording farm histories passed down and split up through inheritance.) This concept is at the least very open to question.
Location Time & Date
(Every location has both a time and date element. This is not to say that these two together define an objective, absolute location.)
GEDCOM and Places
The existing GEDCOM identifier for a place has unlimited levels separated by commas, with a limit of 120 characters; it also supports naming the jurisdictional entity titles with the PLAC.FORM element. A global default place hierarchy can be defined in the HEADER, which is overridden by a local PLAC.FORM entry. It is incorrectly assumed that GEDOM only supports 4 levels : (1) city, (2) county, (3) state, (4) country. Two more lower levels are needed prior to the city. (1) location within site, and (2) site. The site would be the specific place of interest within the city. It can, for example, be an address or the name of a building or a park or a cemetery. The location within site would be used to subdivide sites, e.g. bedroom, Apartment B210, or Section 3; Row 4; Plot 40.
Therefore, an entire location might be something like:
- Section 3; Row 4; Plot 40, Silver Plains Cemetery, Winnipeg,, Manitoba, Canada
where two commas indicate a missing placeholder (in this case, the county). [Missing placeholders are not relevant to BetterGEDCOM.]
Missing placeholders are not needed for leading levels. e.g. if the first 5 levels are left out, then no commas are needed, e.g.:
Location Name Changes, over time.
Jurisdiction Changes, over time.
This is a reality, but there may be a need to acknowledge this and to provide for a date associated with the Location Entity.
I think it's up to the sending and receiving application to do the mapping of where the Location is, and its details, like GPS coordinates, but either the sending or receiving application may have allowed for a "historical" location name, and the receiving application may not. (or the other way around).
If the Location Entity is associated with a Fact or Event, and that fact or event has a date associated with it, what impact does that have on the Location Entity. Does that date need to be associated with the Location Entity?
That date might have an indication that the Location Entity was a "historical" location name.
Just asking the question.
Thank you,
Russ
It seems like you do not support events for places just because you are not used to it. That is not a very good reason. Don't you see that places can appear in sources without being attached to a person? Are other practices that what you are used to forbidden?
I reserve the right to be completely wrong all the time as well as to change my opinion.
In this case, however, I think places already have events. Just as a person has a role in any event, so does a place. Perhaps I just don't understand it. On the other hand, perhaps the idea of events for places is mostly an idea suitable for geographic applications. Either way, I think it's probably up to the user and the application to decide.
But basically, I still don't get it or understand it. Or do I?
For instance, "Greater Manchester Metropolitan County" was created in 1974. It was abolished in ... (whenever). I don't think just putting a time on the name conveys the full meaning. I think we need to record the creation event, linked to the location.
OK, you may wonder why I want to record this in a family history data file, but I might, not least to record why Manchester changes from Lancashire to Greater Manchester to Manchester(?).
Such an event is, I believe, to look at the file, a top-level entity in its own right, which is linked to the place.
I'm pretty sure a person paid any such taxes, whether or not the name is mentioned. Such information strikes me as good evidence, but I don't think that's an event because there's no person. That's just me, though.
However, if the real issue here is whether or not a person reference is mandatory to enter an event. What are the implications if there is no person reference requirement? None that I can think of.
This is essentially incorporating the requirements of timelines, or so it appears to me.
Overall, I think the idea is absurd for my own usage. However, I can also see that other people might consider me an obstinate dunderhead for thinking so. Really, what I think doesn't matter.
If what you're talking about here is really just an event without a person requirement, right now I'm not seeing that as a problem from the standpoint of the data model. However, I would like to see this discussed some more and in the context of incorporating timeline information.
That's certainly what I've been thinking of - events would be top-level entities (if there is such a term), potentially without any relationship to _any_ other entity.
And I don't see any issues from not having any related person, place, group or whatever.
My example is that I might enter some basic information about the San Francisco earthquake just in case my GG uncle was involved in it. That would be entered first, without a linked person because I'm not quite sure at the start whether he's involved or not. Then I add the relation to San Francisco and only later do I add a relation to him.
Or another example might substitute a global trade depression, where no place applies (OK, apart from Planet Earth).
However, having dates in locations, are useful for many purposes, Something that mere events will have trouble unifying.
I have three examples to consider. I'm going to play fast and loose with the real history of the locations, because I have no desire no to research it an give a correct history.
Lorentz Rambshurster died in 1683, leaving the family farm to his three sons. The Rambshurster farm split into three farms with new names at the date of the proving of the will in 1685.
From one location you now have three, with separate futures (pasts to us). You could create an event and link the three places and the original one, giving roles to each place. Or you could create three new places (you have to anyway), and link all three to the parent location. Now you have a location history tree. From 1685 forward you have one name for a portion of the Rambshusrter farm and prior to that another name. I say, it's easier to trace back to find where to search by following the location tree , than it is to find the relevant event.
Example two 1849, Wisconsin Bad Axe County is formed. Laura Larson is born in Coon Valley Bad Axe county in 1863. In 1865 Bad Axe county is renamed. In 1866, Bad Axe County is divided into Jones County and Trempeleau County. In 1868, Lars Larson and Chritine Larson die of influenza and Laura moves in with her sister. In 1870 Laura is found on the 1870 census in Trempeleau County. But no birth record is found for her, because she wasn't born in Trempeleau County. Her record is found in Jones County, because the County seat of Bad Axe County is in Jones County, not Trempeleau. Now certainly you coul make events for the renaming and for the county splitting, and then pray you can remember what those events were, without having to read through the event list. Or You could use the fact that Trempeleau County's parent location is Jones County, and that Jones County's parent is Bad Axe County, and the name of the County in 1863, was Bad Axe County. So, I could either search the events to find that out or make two clicks of the location parent link and find it two clicks away.
Are we burying events into locations by giving them dates? Sure! But does it make research easier? Sure thing!
Third example Hesse-Cassel. That should be all I need to say on that, to anyone who has ever done ANY research in the former state Hesse. Hesse has had so many changes over the years, I just use one name for places in Hesse and damn the consequences. If I had a way to link places along a timeline in Hesse, oh how easy it would be. You want to make me search through a dozens/hundreds/thousands of events that happened to Assenheim over a three hundred year span of my family living there to find the proper name of Assenheim, Hesse-Darmstadt/Rodelheim-Salms/Rodelheim/Salms/Hesse/...? Forget that! But let me travers a timleline location tree towards the root, and I'd be happy to oblige.
Am I lazy. Whenever I can be, absolutely. Sometimes you don't need to know the whole history of a place to fill your needs (like choosing the right name to use for an event).
You might want to look at how I envisioned it in my proposed model. http://bettergedcom.wikispaces.com/PLACE+%28BJD%29
Maybe I've convinced someone that dates in Location are a useful thing? If not, I gave it my best shot. Sometimes you don't need an event, you just need a reference point.
The phrase that shook me out of my intransigent position was: farm genealogies. I do Swedish research. That concept I totally get. Please disregard anything I might have said earlier.
After all that is the point of the project, to look outside the box and find a Better GEDCOM, from a researcher standpoint. Not from a geek standpoint. I admit I have issues thinking as an end user at times. I'd like to know if I convinced Louis?
The examples in your previous entry are concerned with efficiency. I do not think a single pointer to a parent entry will be a sufficient, but there is nothing preventing a program from implementing internal structures to speed up things – if they need to. You are mixing implementation and transfer format.
You can not store the needed information in simple pointers, you need events. Also it seems like you are mixing relations between localities (and their parent/child locations) and the relations between localities on different levels in the location hierarchy (eg. city, country, county).
No one is forcing you to enter all information in the complex examples you describe, and you should not prevent others from doing it.
Secondly, efficiency is good. We should strive for an efficient data model. Third a pointer always resolves to something that that is a data object which contains the desired information. The reason to use a pointer if to prevent writing duplicate information over and over again. The current GEDCOM model makes liberal use of pointers. I see no good reason to alter that approach.
Third there is still much that needs refining in my data model. If a single pointer is not sufficient a linked list or tree of data pointers can be used. I'm not mixing relations between localities and the parent/child and different jurisdictional levels. I failed to include the pointer (or reference if you like) to the next higher jurisdiction. I'll fix that soon. But, I may wind up throwing this version away and doing something slightly different. This approach I proposed has some very real problems. But it is a starting point.
I'm not advocating the need to do or force or prevent any of the examples I gave. I am simply trying to point out the real world issues that will happen and have happened. We should plan for these things.
I'm merely trying to get a concrete model in fornt of people to get the design going. It's easier to tackle the theory, requirements and building of a data model if you have something concrete you can refer to and mark up. Theory is great but it lacks form. People tend to be much more visual. Plus this is such a complex task it'd be hard for the average person to memorize every detail.
Adrian, has made some very insightful comment on my place model. Talking of taking out the name from the record and placing them in an array or tree or some other type of heirarchy as a characteristic. THe dates would naturally go with them.
I'm not saying that the names aren't an event, but that this is a good case where duplication of some of that data is a good thing. If you want to make an event out of it, my model doesn't prevent that. My whole point with dates with the location names is purely for the convenience of the researcher.
Say you have to add a child born in 1734 in Assenheim. In 1734 Assenheim belonged to the Solms Barony In 1724 it belong to Rodelheim. In 1784 it belonged to Solms-Rodelheim. So the child's parent was born in Assenheim, Rodelheim, Wetterau, Hessen-Darmstadt, Holy Roman Empire of the German Nation.
The child was born in Assenheim, Solms,... . That child's child was born in Assenheim,Solms-Rodelheim....
Now would you rather search through a lot of history to look up which name to use when entering a new birth, or would you rather get a pull down list of places, you've already entered, with a date range and simply choose the right one.
If you think my examples are complex, I should tell you my genealogy is full of complex examples like this. I have thousands of records and fully a third of them are on farms in Sweden and Germany absolutely riddled with property splits and name changes, and district changes. This Assenheim example was one of the simplest. I could have chosen a farm in Sweden. But then the example would take up pages to fully explain. I have numerous American examples too. My family settled in New Haarlem in 1652.
I want a new GEDCOM, that will be efficient and assist me in the speedy entry of information, not one that bogs me down more. Forcing users, or programs, to search events to find out which placename to use for a new event is going completely discourage users from adopting the model and will lead to a worthless WorseGEDCOM. At least in my opinion.
Adding events for location name changes is worthy in it's own right, but it does nothing to solve the problem of finding quickly which darn name to use. There are 500 placenames (full) in my tree, and that's ignoring all the name changes. Because it's simply too much work with existing programs and GEDCOM to add the thousands of place names I should be using.
I have the same thing, Hall family property was changed later to Rose Hill in Copiah Co MS. I think I will have to think on that because I have the same problems for many entries. maybe a link from one Source ID or something to point saying equal = Location?
Even worse when street names change and your at the same address # town city and state, just the street change looks like a move?
Those are like aka names pointing both at the personID and sourceID.
A place has a name change, say with the idea of some to have a GPS location,
Say GPS-evidence or location-evidence,
That data set would link Location to source and on the evidance records could list all the aka names like we would for a persons aka names?
What do you think?
So to me, the change of the location name could be marked as an event associated with the location. If you don't like that, then the alternative would be to have a "name" element for the location that has a date-range associated with it.
One doesn't need the entire history of a place in one's database to print a report about all the events that happen at that place. Likewise, a place may very well be relevant to a person without their having been present for all the events affecting that place's name or jurisdiction.
No one is suggesting that historical events related to how a place name might change aren't relevant to a person's life. However, they may or may not be. you're essentially requiring that such information be entered. This is what I don't think is realistic.
I think people should be able to record as much or as little about a geographic place as they want. I don't think that to refer to a place in West Virginia that a person must enter events about Acts of Congress during the Civil War into their genealogy database.
Now I think part of the argument is becoming clearer: Locality as a set of coordinates versus a place with historical context.
I firmly stand in the idea of places as important in their historical context. Time element is important. So is jurisdictional context when jurisdiction is in dispute. Certainly physical location is very important, but within the limited scope of the use of place information in genealogy, I don't see value in referring to places as mere coordinates. Taking places out of their historical and cultural context for reference doesn't suit my needs. If my ancestor referred to his home in what is now Delaware as Sverge Nova (or whatever), I want it recorded in my database like that. I don't want it converted to mere physical coordinates. I also don't want it referred to as Delaware or New Netherland, Maryland, Pennsylvania, or any other possible definition of its jurisdiction, depending on who you ask.
I think what you're looking for is better accomplished in geography tools.
I think the time aspect relates both to the location/place and it's name(s), but if this can be handled by events alone is difficult to say at the moment.
Don't mix up how the program presents the data to you from how it is stored.
For database purposes, normalizing the essence of a "location" is that it is not a set of coordinates, but it is the object you are talking about. e.g. A certain city, a certain house, a certain cemetery plot.
The coordinates are a data item that describes the location. They are not the location.
Also the name of the location is also a data element about the location. It is what the location was called during a certain time period. It is not the location.
If locations were entered as records in GEDCOM, they should have worked something like this:
0 INDI @I43@
1 BIRT
2 DATE 1853
2 PLAC @P43@
...
0 @P43@ PLAC
1 NAME Townsville
2 DATE From 1832 to 1912
1 NAME Citiesville
2 DATE From 1912
1 LATI N18.150944
1 LONG E168.150944
Now the program should be smart enough to accept either accept Townsville or Cityville as the birth place when it is entered. And it could even be smart enough to display the name of locations as they were called at the date of the event.
But the main thing is you have one unambiguous place that can be a single entity.
My thoughts exactly. I would also point out that we're not talking about a "program" here. We're talking about data.
The data I'm worried about is that which was used to describe the place in context. I totally agree that reference data for geographic information systems such as coordinates or URIs for specific systems like Google Maps or whatever should be included.
"...normalizing the essence of a 'location' is that it is not a set of coordinates, but it is the object you are talking about."
WHAT!?!?!? Normalizing data has nothing to do with anything except the data as it is manifested. Data in a database is not manifested as a house or city or a cemetery plot. Perhaps that the 16th normal form? </smirk>
"But the main thing is you have one unambiguous place that can be a single entity."
Unfortunately, in reference to genealogical data in particular, it's neither possible nor particularly desirable to reduce absolutely everything to an unambiguous place.
Places have various location reference information, descriptive information (including time, jurisdiction, etc.), and they may or may not be identifiable as unambiguous places. As much as one might like it to be so, places cannot be universally defined as absolute or unambiguous thingamabobs, at least for the purposes of genealogical research. You'll have too much data fall outside such a definitive model.
Greg,
Well, I guess here we'll have to agree to disagree. We seem to be thinking completely differently on this.
Louis
Actually - why?
What problems would there be if we allowed both?
I agree that the Place information be free form. There may be the need for other attributes, but the date is not one of them.
Reason: As a place name changes overtime, it's the application that is giving me, the end User, some indication that the place name, in the database is right or wrong. The database or the end user needs to determine if the place name, as presented or shared. The application or user would need to know if that Place name was correct for that date that an event took place.
Bottom line, the date for a place, is not important for the BetterGEDCOM. In my opinion.
Russ
I still have no idea how you get to a point at which places have events. Frankly, in a genealogy database, I think the idea is absolutely absurd. Whatever that's worth.
Russ,
I think you're confusing data a user might need or want with teh data needed for particular information in a database. Regarding places, perhaps a date VALUE isn't imperative, but the ability to enter one is. If you're suggesting an application offer the ability to allow or deny use of a particular place field based upon a time constraint, where exactly do you think that time constraint value is going to be stored?
A time element, whether used or not, is certainly critical to a location entity. Perhaps not for a particular entry, but regarding database structure, it's key.
If the name of the country changes, then it is a name change event, just as if a person's name changes.
Perhaps if we were talking about geography data, your observation might be apropos. However, in genealogical research, associating dates with places is entirely reasonable. Requiring events to supply time relevance for a geographic location is not.
Absolutely not!
Events happening at places are EXTREMELY individuals. Events in the town of your grandfather affected his life and may give you clues as to some of his history you may not know.
If you find out that there was an influenza breakout in his town, and some of his family died around then but you don't know how, where else do you document information about this breakout unless you associate it with the town? There needs to be one place to store this and the location is the logical place.
These items then can go into timeline programs that can put your ancestors lives into context.
Unless I've got somewhere to properly store all the info I've collected about my ancestral towns in my genealogy program, then I'll look for another genealogy program.
And if BetterGEDCOM cannot transfer this information (events about the towns) to another program, then I'll look for a GEDCOM better than BetterGEDCOM.
... are EXTREMELY important.
Locations are in most cases properties, and I assume that in most countries there are legal documents produced when this type of location is created – e.g. by a splitting a larger property or when two or more smaller properties are merged – or a combination division/merging. These are the birth and death events of a property (or location.) – and note - in most cases involving two or more locations.
Other events are name changes, census records, tax lists, statistics, transactions.
Unfortunately only a couple of programs are able to produce proper reports documenting the history of a location and the families that owned it or lived there, with photos and maps. Producing such reports is the only way I know that allows you to document the genealogy of a population in an area – without a lot of duplication of info.
Genealogy is microhistory. You're suggesting that to express any difference in a place's name, we need to enter all the historical references to that place, particularly in regard to how that place name might change, to persons. That's not realistic.
No one denies that events happening related to place changes aren't important. What is doubtful is that such events are likely to be part of anyone's genealogy. Conversely, we are not likely to suggest that someone enter all the events relevant to US History to study and document their American ancestors in their genealogy software.
If location information is relevant to someone's genealogy because their ancestors lived there at the time and it might lead them to hypothesis and conclusions, then they probably would want to enter that information somewhere they can review it. Isn't that realistic?
And if locations are made an entity in BetterGEDCOM, and if program designers are going to use BetterGEDCOM, then they will finally have the capability to produce proper location reports that include information and events about the location, as well as links to all the people events that refer to the location.
You can see a location as point in a 2- or 3-dimensional space, defined by coordinates.
Time adds a 4th dimension.
What IS at a location at a certain time? Still only a location. What happens there? An event.
That's if you take location as a point in a coordinate system.
But if you give that location a name, like "Miller Manor", then that thing has a time-span (life-span). That thing also still has events.
But how is that relevant to BG?
What do we want to record, and how?
What Louis said made me think of village histories (chronicles?) or house histories. I think that those aren't geneaology, but very closely related. So if we could make the BG standard accomodate both, I think genealogy could profit. I don't think we should make the standard support everything that's necessary for village chroniclers.
Another traces and ancestors movements during the Siege of Quebec (1775).
During WWII, military photographers caught pictures almost any where they could. One day, all the work about my father's time line, locations and group assignments might lead to some great "captured on film" moments.
:) --GJ
I think the issue with the Location Entity is NOT the Place, but the Location Name at a point in time. The same GPS coordinates, but the name of the jurisdiction name changed.
Millers Manor in YYYY
Smiths Manor in YYYY+10ys
Same place, different owner and different name.
Russ
Basically I think all locations need their own date entity. How an application deals with working out that date and any conflict it might have with an event's date is out of our purview.
Thus is something happens at a time, what you have is an event. I believe we should allow events to be associated with a location.
Example: Your grandfather's house is the location. The events might be: House built in 1804 by Jack Jones. Kitchen added by John Jones is 1823. Fire in 1846 destroyed shed, etc.
There could also be objects associated (e.g. pictures) associated with the location, and evidence to support events, etc.
A location is almost like a person. The subtle difference is that events for a person happen at a time at a certain place. Whereas events for a place happen at a time possibly with certain people.
This has more to do with the NAME of the Place at a given point in time. For example, the township that I grew up in, no longer exists. My brother and I graduated from the same building, but the name of the town had changed the year between our graduation.
Russ
I would appreciate that you restore the Wiki Page to it's previous state. You deleted, what I consider, important aspects of this element.
Thank you,
Russ
Russ,
I deleted very little. Please add back in whatever it is you feel that was important.
The key point is that assigning a date-time to a place will is effectively allowing events for places. And doing the latter is something I see as necessary and would be the correct way to implement the date-time assignment.
But, the issue at hand, is the "name" of the Location at a specific point in time.
How are you proposing that a Location changed it's name over time?
Russ